Date: Thu, 6 Oct 94 04:30:02 PDT From: Advanced Amateur Radio Networking Group Errors-To: TCP-Group-Errors@UCSD.Edu Reply-To: TCP-Group@UCSD.Edu Precedence: List Subject: TCP-Group Digest V94 #221 To: tcp-group-digest TCP-Group Digest Thu, 6 Oct 94 Volume 94 : Issue 221 Today's Topics: antenna switching time (2 msgs) radio switching times WG7J, Author of JNOS (forward) (2 msgs) Send Replies or notes for publication to: . Subscription requests to . Problems you can't solve otherwise to brian@ucsd.edu. Archives of past issues of the TCP-Group Digest are available (by FTP only) from UCSD.Edu in directory "mailarchives". We trust that readers are intelligent enough to realize that all text herein consists of personal comments and does not represent the official policies or positions of any party. Your mileage may vary. So there. ---------------------------------------------------------------------- Date: Wed, 5 Oct 1994 06:02:33 -0700 From: myers@bigboy73.West.Sun.COM (Dana Myers) Subject: antenna switching time > Date: Tue, 4 Oct 1994 10:00:11 -0600 (MDT) > From: Klarsen > Been reading how guys are trying the 9600 baud modems at 19,200 > baud and now are looking at switching times. About time too. I have a x1j > node that is using a Motorola Railroad Micor radio (we got 100's of these > at $25). It is on 145.070 MHz and is a 1200 baud Tiny-2 tnc. I > experimented with the tx delay and found that this radio takes about 0.4 > seconds to go from receive to transmit! How did you measure this? By changing TXDelay up and down during a connection to some other radio? My experience with Micors in general is that they switch pretty quickly; I have a 110W VHF High-band radio in service that happily works with a TXDelay of 100mS. Remember, the TXDelay allows time for both (a) the transmitter to start transmitting and (b) the receiver on the other end to start receiving. If the remote receiver is using squelch, the time required to break squelch can be quite long, greater than 250mS, depending on the radio. My empirical tests of the Micor was against a remote station using open-squelch DCD. As I said, 100mS of delay was plenty. > At 1200 baud .4 seconds is not a real problem, but is an > agrivation that makes you want to put in an electronic switch. But not > quite. When you get to 9600 baud you begin to see the problems. I have > just mounted a Comet 145.07 and 445.01 MHz antenna that will have a Tekk > radio with a tx delay of .02 seconds running 9600 baud and it's tnc will > be connected to the older 145.07 1200 baud system. At some later time I > plan to make the the 145.07 system run at 9600 baud. Are you *sure* the problem is the T/R switch in the Micor? I've never looked at the railroad Micors; is there something special about the T/R switch that isn't in the conventional Micors? On another note, VHF High-band Micors are generally phase modulated. This tends to present an issue for 9600 baud operation; you really need to have a direct FM radio. You can make high-band Micor do direct FM; you either install a complete Micor repeater exciter and 4 pin channel elements (also found in the DVP Micors, but these are pretty rare) or you install a 4 pin element in a PM exciter, disable the PM modulator, and wire the modulation to the "fourth" pin of the element. The receiver IF also may need some attention, too. > Now that .4 second looks HUGE! It takes 1 full packet time to > switch that old radio. So something new must be invented, or a new way to > use the radio so it isn't a problem. The only thing that comes to mind is > a duplex radio that has no antenna switch and the transniter is just left > on until packets stop coming. Since I've looked at several Micors, and none of them had excessive T/R delays, I'd suggest you have a look and understand why you're seeing this 400mS T/R time. It could be your remote receiver is very slow; it also could be some artifact of how the Micor is set up. It should be possible to get this radio to perform much better. Dana KK6JQ ------------------------------ Date: Thu, 06 Oct 94 14:06:55 +0900 From: Ryuji Suzuki -- JF7WEX Subject: antenna switching time |Date: Tue, 4 Oct 1994 10:00:11 -0600 (MDT) |From: Klarsen |Subject: antenna switching time | Now that .4 second looks HUGE! It takes 1 full packet time to |switch that old radio. So something new must be invented, or a new way to |use the radio so it isn't a problem. The only thing that comes to mind is |a duplex radio that has no antenna switch and the transniter is just left |on until packets stop coming. | | Do you have any ideas or tried solutions? I also think that full-duplex is effective for data to be transmitted with high bit rate, but its application for practical connections except for point-to-point ones would be rather hard. Delay to responce in magnetic relays or other switching devices must not dominate the delay time to transmit. Typical set/reset time for magnetic relays ranges from a few milliseconds(for signal) to twenty milliseconds(for large power). I think elements that affect the delay time are time constants in DC power lines or bias circuits, oscillator startup time, and PLL lock-in time. -- Ryuji Suzuki JF7WEX ------------------------------ Date: Wed, 5 Oct 1994 07:31:13 -0800 (PDT) From: Glenn Elmore Subject: radio switching times Karl k5di wrote: > At 1200 baud .4 seconds is not a real problem, but is an > agrivation that makes you want to put in an electronic switch. But not > quite. When you get to 9600 baud you begin to see the problems. I have > just mounted a Comet 145.07 and 445.01 MHz antenna that will have a Tekk > radio with a tx delay of .02 seconds running 9600 baud and it's tnc will > be connected to the older 145.07 1200 baud system. At some later time I > plan to make the the 145.07 system run at 9600 baud. > > Now that .4 second looks HUGE! It takes 1 full packet time to > switch that old radio. So something new must be invented, or a new way to > use the radio so it isn't a problem. The only thing that comes to mind is > a duplex radio that has no antenna switch and the transniter is just left > on until packets stop coming. > > Do you have any ideas or tried solutions? > I don't know about the Motorola but I think you may be in trouble with 20 milliseconds on the Tekk radio. I see this after measuring and taking notes on only one Tekk KS960 which was fresh from Tekk a few days ago. I hope to clean up my notes and post them. What I found was that the Tekk receiver was very slow in recovering after the radio transmits. While it can go from assertion of PTT to full power in a millisecond or so, getting the receiver back to full sensitivity after letting go of PTT takes about 40 milliseconds. I ax25 connected two Tekks back-back with a single TAPR Modem/TNC2 and verified that things broke at 20 ms TxDelay. They still worked at TxDelay=30 ms but that was with very strong signals. I don't yet even have a schmatic of the radio so can't determine who the culprit is, whether supply switching, saturation of an amplifier stage or something else. All I know at the moment is that the RSSI line doesn't find full signal for a long time after negating PTT. There may be a reasonable fix for this problem. I don't believe that duplex is necessary for fast turnaround times. The highspeed radios we are running are presently being used with 1 ms txdelays but this is only because that's the smallest value the PI2 card drivers presently allow. The radios work fine at 50 microseconds and are not FDX. They use PIN switches for T/R and I took only a little extra care in how things were switched inside the radio. No crystal oscillators have to start up when things are switched and time constants associated with filtering are kept to reasonable values. It's not useful to "filter the heck out of it" to make things perform cleanly and quickly. You may have seen my original estimates that the radios are fast enough and sensitive enough to copy their own *packets* by aircraft-bounce with the planes at 5-10 miles distance using only an 8' or so antenna. Certainly we don't need packet radar for most amateur networking but making fast non-FDX radios isn't all that difficult. Glenn Elmore n6gn amateur IP: glenn@SantaRosa.ampr.org Internet: glenne@sr.hp.com ------------------------------ Date: Thu, 6 Oct 1994 09:44:32 +0900 From: Isao SEKI Subject: WG7J, Author of JNOS (forward) Hello group, This is a forwarding message, original by JF1LZQ Yutaka Sakurai. Isao, JM1WBB --- forwarding message This is just FYI. I suppose that many of you would know the JNOS, another TCP/IP software for packet radio which includes "Converse" as well as RBBS gateway feature. Johan. K. Reinalda (WG7J), the author of JNOS, is living in Miyazaki Japan now. He has just joined PRUG-net and his email address is wg7j@kban-gw.kban.prug.or.jp The kban.prug.or.jp is connected with PRUG-net backbone by UUCP. The PRUG-net is Japan's AMPR network which is build not only with packet radio TCP/IP but also ISDN as well as leased line. PRUG-net backbone is connected to the INTERNET through the comercial internet provider by IP. * PRUG : Packet Radio User's Group --- end of message ------------------------------ Date: Wed, 5 Oct 1994 17:36:28 -1000 (HST) From: Antonio Querubin Subject: WG7J, Author of JNOS (forward) So when will the Japan AMPRnet join the other 'connected' AMPR nets? Antonio Querubin tony@mpg.phys.hawaii.edu / ah6bw@uhm.ampr.org ------------------------------ Date: Wed, 5 OCT 94 14:17:08 From: ANDERSONR%DELPHI@xmail.cns.thiokol.com SUBSCRIBE TCP-GROUP BOB ANDERSONR AA7TR ------------------------------ End of TCP-Group Digest V94 #221 ******************************